Historisch gesehen ist die Motivation für diese Initiative am ehesten verständlich. Durch die stets weitere Verbreitung der plattformunabhängigen Programmiersprache Java Ende der 1990er Jahre sah Microsoft seine Dominanz in dem Bereich der PC-Kerntechnologien in Gefahr. Zudem war es Microsoft bis dahin nicht gelungen, in dem lukrativen Markt für mobile Kleingeräte Fuß zu fassen.

Microsoft übernahm die von SUN entwickelte Java-Technologie für sich und erweiterte sie nach den eigenen Bedürfnissen, wodurch die Plattformunabhängigkeit in Mitleidenschaft gezogen wurde. Als SUN dies unter anderem durch Gerichtsverfügung unterband, wechselte Microsoft die Strategie. Um eine vollständige Unabhängigkeit von anderen zu erreichen, sollte die .NET-Plattform von Grund auf neu entwickelt werden.

Zu dem vom Marketing getriebenen Wunsch nach einer konkurrenzfähigen Technologie "gegen Java" gesellte sich eine überfällig gewordene technische Innovation: Die technologische Basis der Windows-Programmierung, nämlich die Objekttechnologien COM und DCOM, hatten ihre Grenzen erreicht. So entstand ein aus vermarktungsstrategischen Überlegungen und technischer Notwendigkeit motiviertes gemeinsames Projekt.

Eher untypisch für Microsoft wurde dafür eine Reihe der prominentesten externen Fachleute, die sich in der Windows-Welt einen Namen gemacht hatten, zu Microsoft geholt, was sich an vielen Stellen in der technischer Qualität und Innovation niederschlug, aber auch die Akzeptanz in der Entwicklergemeinde erhöhte. So wurde z.B. die neue .NET-Sprache C# federführend von dem Turbo-Pascal-Erfinder Anders Hejlsberg entwickelt. Die verschiedenen Teiltechnologien wurden in mehreren weitgehend unabhängigen Gruppen entwickelt, wodurch die Entwicklungsgeschwindigkeit wohl erhöht, die Homogenität der verschiedenen Bereiche aber verschlechtert oder verhindert wurde (s. Ausblick).

• 2000, Juni – Bill Gates stellt erstmals die .NET-"Vision" vor, zunächst unter dem Codenamen "Whistler"
• 2000, Juli – Auf der Entwicklerkonferenz PDC gibt es erstmals CDs mit lauffähigen Vorabversionen des Frameworks und von Visual Studio .NET
• 2000, Oktober – C# und die CLI (s.u.) werden (von MS, HP und Intel) bei der Europäischen Standardisierungsorganisation European Computer Manufacturers Association ECMA eingereicht, was für Microsoft einen ungewöhnlichen Schritt der Öffnung darstellt.
• 2002, Januar – .NET (V1.0) wird offiziell mit der zugehörigen Entwicklungsumgebung SDK (und Visual Studio 2002) vorgestellt.
• 2001–2002 – Verwirrung: In dem Zuge des Marketings wird nach Microsofts Gewohnheit versucht, alle anstehenden Neuentwicklungen unter einen, den .NET-Begriff, zu fassen, wodurch selbst Fachleute einschließlich Microsoft-Mitarbeitern nicht mehr verstehen, worum es eigentlich geht. Die Programmiertechnologie und Entwicklungsumgebung wird erstens in Verbindung gestellt zu konkreten Webdiensten, die Microsoft anbietet (Codename "Hailstorm" wird zu ".Net My Services" und später vom Marketing wieder von .NET entkoppelt). Auch die nächste Betriebssystem-Generation von Windows wird als Bestandteil von .NET angekündigt. Interessant ist hier die Begriffs-Historie beim Server:
  • 2000, Januar: Codename "Whistler Server"
  • 2001, 30. April: Windows 2002 Server
  • 2001, 19. Juni: Windows .NET Server
  • 2002, 27. August: Windows .NET Server 2003
  • 2003, 9. Januar: Windows Server 2003 (wieder ohne .NET)
• 2003 Vorstellung von .NET 1.1 und Visual Studio 2003 mit in dem Wesentlichen kleinfügigen Verbesserungen und Erweiterungen.
• 2004 Obwohl technisch schon einige Jahre alt, steht der Marktanteil an .NET-Programmen stets noch in keinem Verhältnis zur Aufmerksamkeit in Medien und Entwicklergemeinde. Insbesondere auch Microsoft selbst hat keine in der Breite bekannten, komplett mit .NET programmierten Anwendungen veröffentlicht, was sicherlich auch Zeit und Aufwand demonstriert, die technische Umstellungen benötigen.
• 2004 Betaversionen von .NET V2.0 und Visual Studio 2005 erhältlich.

• Für 2005 ist die nächste Version von .NET V2.0 und Visual Studio 2005 angekündigt, die neben starken Erweiterungen der Klassenbibliothek einige Vereinfachungen des Programmiermodells mit sich bringen soll.
• 2006–2007 Nachfolgetechnologien als Bestandteil des Windows-XP-Nachfolgers mit Codenamen "Longhorn" sollen die Redundanzen in aktuellen .NET-Teiltechnologien beseitigen, insbesondere die APIs zur Web- und Windows-Oberflächenprogrammierung vereinheitlichen und ein fortschrittliches Konzept für verteilte und insbesondere serviceorientierte Architekturen bereitstellen und damit das weitgehend unstrukturierte Nebeneinanderher von Web Services, .NET Enterprise Services und .NET Remoting Services beseitigen.

Die .NET-Plattform stellt mit der Common Language Infrastructure (CLI) eine Basis zur Ausführung von Programmen, die mit unterschiedlichen Programmiersprachen erstellt wurden, her. Dies wird durch die Verwendung einer (objektorientierten) virtuellen Maschine und die Framework Class Library (FCL) – einer gemeinsamen Klassenbibliothek – erreicht.

Die Common Language Runtime (CLR) ist die virtuelle Maschine (VM) von .NET und stellt somit die Laufzeitumgebung für verschiedene an .NET angepasste Hochsprachen zur Verfügung. Die VM führt den standardisierten Bytecode der Microsoft Intermediate Language (MSIL) aus. Hierfür wurde ein sprachübergreifendes System von objektbasierten Datentypen definiert, so dass auch in unterschiedlichen Sprachen geschriebene Programmteile auf gemeinsame Ressourcen zugreifen können. Das von Vorneherein in dem Gesamtkonzept berücksichtigte Nebeneinander mehrerer Programmiersprachen unterscheidet .NET von anderen auf Bytecode basierenden Laufzeitumgebungen (z.B. Java Virtual Machine, s. Java).

Das Besondere an der CLR ist weniger die technische Innovation als vielmehr die strategische und (langfristig vielleicht folgenreichste) Entscheidung des Marktführers Microsoft für ein CLR-basiertes System, das u.a. Programmierfehler vermindern soll und gegen die traditionelle direkte Kompilierung in den Maschinencode deAbsichtsystems.

Die Entwicklergemeinde von C++ für .NET zu gewinnen, ist nicht zuletzt nötig, um .NET zu dem Erfolg zu verhelfen. Geschwindigkeit war bei .NET deswegen von Anfang an ein wesentliches Designkriterium. Dies ist ein wesentlicher Unterschied zu den ersten JVMs.

Da sich jedoch .NET und JVMs technisch gesehen sehr ähneln (interpretierter Bytecode wird auf stackbasierter VM ausgeführt und von einem JIT-Compiler dynamisch optimiert), ist die Ausführungsgeschwindigkeit der Java-Implementierung von Sun mit der .NET-Laufzeitumgebung von Microsoft vergleichbar.

In der .NET-Sprache gelten alle Programme, die innerhalb der CLR laufen, also für .NET geschrieben wurden, als managed -- alle anderen, insbesondere ältere Programme, damit quasi abwertend, als unmanaged. Mit Hilfe der so genannten "Interop"-Technik, lassen sich insbesondere traditionelle (Microsoft-)COM-Programme mit .NET-Hüllen versehen und danach deren Klassen wie .NET-Klassen aufrufen. Umgekehrt lassen sich auch .NET-Klassen wie COM-Klassen aufrufen. Damit soll eine fließende Umstellung von Projekten auf .NET ermöglicht werden.

Die bisher einzige Sprache, mit der man sowohl managed als auch unmanaged Code in einer einzigen Programmdatei mischen kann, ist C++/CLI (Managed C++).

Eines der wichtigsten Konzepte ist das Sicherheitskonzept von .NET, das weit über das bisher in Windows verankerte oder etwa das von Java hinausgeht.

Das Sicherheitskonzept von .NET fängt an bei Mechanismen, die die Identität des Programmherstellers gewährleisten sollen (Authentizität), geht über Mechanismen zu dem Schutz der Programme vor Veränderung (z.B. vor Programmviren) bis hin zu Schutzmechanismen, die den Ort der Herkunft bzw. Programmausführung (z.B. Internet) einbeziehen. Es gibt technisch betrachtet sowohl ein codebasiertes (Code based Security) als auch ein nutzerbasiertes (Role based Security) Sicherheitsmodell. Spezialisten stoßen allerdings insbesondere bei der Web- und Datenbankprogrammierung unter .NET auf bis zu ein halbes Dutzend alternativer und ergänzender Sicherheitsmodelle von Betriebssystem, CLR, Datenbank und Webserver.

Übersetzte Programmklassen werden als ausführbare Programme in so genannten Assemblies zusammengefasst und bereitgestellt (vgl. mit Packages/Paketen in Java). Diese haben typischerweise die altbekannten Endungen .exe oder .dll, sind intern jedoch völlig anders strukturiert. Insbesondere sind in dem so genannten Manifest alle notwendigen Metadaten aufgeführt, so dass für reine .NET-Programme in der Regel die gewohnte, aber aufwändige und fehlerträchtige Registrierung (siehe Registry), wegfällt (Ausnahme z.B. COM+/Enterprise Services).

Eine, wenn auch zunächst rein programmiertechnisch interessante, Neuerung von .NET ist die Einführung von Attributen, d.h. als solche gekennzeichnete Metadaten als Bestandteil der Programmiersprache. Beispielsweise können in dem Rahmen der komponentenbasierten Programmierung Komponenten Merkmale ausgedrückt werden. Es können für die Verteilung, Installation und Konfigurierung, für die Sicherheit, für Transaktionen und viele andere Anwendungen dem Code beschreibendes Merkmalen hinzugefügt werden.

Microsoft bietet hier nicht einen übergreifenden Ansatz, sondern gleich (mindestens) drei unterschiedliche, mit jeweils eigenen Vor- und Nachteilen: eine moderne Implementierung des ersten neuen Industriestandards des 21. Jahrhunderts, Web Services (ab und zu auch "XML Web Services" genannt), eine Architektur für verteilte Programme (im Wesentlichen in dem LAN), die .NET Remoting Services, und die .NET Enterprise Services. Letztere sollen eine Konkurrenztechnologie zu der erfolgreichen J2EE werden, aber obwohl diesmal Microsoft Ende der 1990er Jahre mit dem MTS (Microsoft Transaction Server) eine weithin unbeachtete Innovation lieferte, reagierte Sun und bildete eine vergleichbare Technologie nach, und zwar kommerziell erfolgreich, so dass die Microsoft-Technologie in diesem umsatzstarken Unternehmensmarkt bislang noch keine Rolle spielt.

Die Common Language Specification (CLS) definiert eine gemeinsame Untermenge Binärcode der MSIL, der von der virtuellen Laufzeitumgebung (VM) in den Maschinencode der Absichtmaschine übersetzt und ausgeführt werden kann. Somit ist es möglich, .NET mit verschiedenen, an die CLR angepassten Sprachen zu programmieren. Von Microsoft z.B. schon in dem Visual Studio mitgeliefert sind das, neben der von Microsoft für .NET eingeführten Sprache C#, die Sprachen C++, das proprietäre Visual Basic .NET (siehe auch Visual Basic) sowie J# (Aussprache: dschäi-scharp; eine Portierung von Microsofts veränderter Java-Implementierung) und abschließend - nicht zu verwechseln mit J# - JScript.NET (siehe JavaScript).

Insbesondere das vereinheitlichte Typsystem ("Common Type System"), das eine gemeinsame Schnitttmenge an Datentypen beschreibt, sorgt für eine reibungsloses Zusammenspiel beim Aufruf von in einer anderen Sprache geschriebenen Komponenten.

Neben den von Microsoft für die .NET-Plattform angepassten Sprachen C#, Visual Basic .NET und C++/CLI (Managed C++) werden weitere .NET-Sprachen von Drittanbietern zur Verfügung gestellt (z.B. Delphi von Borland).

Fast unerwartet scheint der Anklang der .NET-Technologie bei Anbietern marktenger Programmiersprachen oder in Forschung und Lehre. Für eine beispielhafte Übersicht vieler Projekte zu .NET-Programmiersprachen sei verwiesen auf [1] (http://www.jasonbock.net/dotnetlanguages.html).

Offensichtlich ist gerade für solche Programmiersprachen die zusätzliche Funktionalität einer umfangreichen (wenn auch zunächst für das marktführende Betriebssystem optimierten) Klassenbibliothek interessant und produktivitätsfördernd.

Die angestrebte Plattformunabhängigkeit ist unter .NET bisher kaum gegeben, da der Hersteller Microsoft die .NET-Plattform ca. für seine eigene Produktlinie Windows anbietet. Eine Laufzeitumgebung (CLR, VM) für das Betriebssystem Linux (und deren Derivate) steht aber, dank CLS, in Form des Open-Source-Projektes Mono zur Verfügung, das vom Hersteller Ximian initiiert wurde. Obwohl sich dieses Projekt aber noch in der Entwicklung befindet (Stand: September 2003) und nicht alle Komponenten von .NET zur Verfügung stehen, ist mit einer hohen Verbreitung auf Windows-fremden Systemen zu rechnen. Daneben wird noch in dem Rahmen des dotGNU-Projekts an einer "Portable.NET" genannten Laufzeitumgebung gearbeitet.

Aufgrund fehlender Normierung der Klassenbibliothek sowie lizenzrechtlicher Probleme kann man Plattformunabhängigkeit in der Praxis allerdings nicht attestieren. Unter dem Aspekt der plattformübergreifenden Verfügbarkeit dominieren hier auch zusätzlich Java-Programme, Umsetzungen mit Sprachen wie Perl und PHP – sowie maschinennahe Produkte, die typischerweise mit Sprachen wie Assembler, C++ oder C erstellt werden.

"Managed code" wird wie oben erwähnt von der Laufzeitumgebung Common Language Runtime (CLR) verwaltet. Diese virtuelle Maschine (VM) übernimmt die Anforderung und Freigabe von Speicher und anderen Ressourcen (Garbage-Collection) und stellt sicher, dass geschützte Speicherbereiche nicht direkt angesprochen oder überschrieben werden können. Wie oben unter Sicherheit beschrieben, können auch Zugriffe auf Dienste, Dateisystem-Funktionen oder Geräte überwacht werden und werden, sofern sie gegen Sicherheitsrichtlinien verstoßen, von der CLR abgelehnt.

Durch verschiedene Techniken wird versucht, den negativen Einfluss der CLR auf die Ausführungsgeschwindigkeit möglichst klein zu halten. Z.B. wurden analog zu Java so genannte "Just-In-Time-Compiler" eingeführt, die einen Mittelweg zwischen Interpretation und Kompilierung gehen. Des Weiteren kann man mit .NET als Neuerung auch Programme in bereits kompiliertem Maschinencode vorinstallieren, wodurch sich insbesondere (und nur) die erstmaligen Ladezeiten bei Programmen mit größeren Klassen- und Objektmengen reduzieren.

Die automatische Ressourcenverwaltung und die verbesserte Sicherheit haben dennoch auch ihren Preis – die Ausführung von managed code hat einen erhöhten Bedarf an Ressourcen und benötigt kleinfügig mehr Zeit . Außerdem sind die Antwortzeiten auf Programm-Ereignisse wesentlich schwieriger zu kalkulieren und zu dem Teil deutlich größer, was die Anwendbarkeit für Echtzeitaufgaben stark einschränkt.

Ein Grund hierfür ist die "Garbage-Collection", die automatische Freigabe nicht mehr benötigten Speichers und anderer Ressourcen. Zu beachten ist hierbei, dass die Freigabe nicht direkt erfolgt, sondern der Garbage-Collector der CLR über den Zeitpunkt entscheidet. Während dies einerseits, durch die Zusammenfassung der Freigabeoperationen, die Ausführungsdauer von Programmläufen verringern kann, können andererseits die Antwortzeiten auf Ereignisse dadurch in Mitleidenschaft gezogen werden. Durch die zeitverzögerte Freigabe entsteht auch ein erhöhter Ressourcenbedarf. Dies ist natürlich besonders für kleinere Maschinen nachteilig, und stellt darum, in dem Hinblick auf die Marktausrichtung zu mobilen Kleingeräten, ein Problem dar.

Bislang wird darum zusätzlich eine große Anzahl von außerhalb der CLR betriebene Anwendungen benötigt, wenn es um die Erstellung ressourcensparender oder laufzeitkritischer Anwendungen geht (Animation, Simulation, Bildverarbeitung, direkte Zugriffe auf Dateisysteme und Geräte, Treiberprogrammierung, 3D-Spieleprogrammierung, KI-Anwendungen, sicherheitsrelevante Anwendungen wie Anlagensteuerungen, usw.).

Auf der anderen Seite steht die Meinung, dass durchschnittliche Qualität und Effizienz der traditionellen Softwareentwicklung zu wünschen übrig ließen und lassen und dass die diesbezüglichen Vorteile durch obige Verfahren deren Nachteile in der Regel aufwiegen. In dem Allgemeinen wird dabei von einer asymmetrischen Verteilung ausgegangen, dass z.B. 90 Prozent einer durchschnittlichen Anwendung problemlos "managed", d.h. auch mit Garbage-Collection ausgeführt werden können, und lediglich 10 Prozent (dann einzelner Funktionen oder Klassen) optimiert werden müssen.

Dabei hat sich -- analog zu den Diskussionen "Assembler – ja oder nein" -- gezeigt, dass häufig durch Optimierung zugrunde liegender Algorithmen und Datenstrukturen eine wesentlich höhere Ausführungsgeschwindigkeit als durch die Entscheidung für oder gegen eine Programmiersprache oder Programmiertechnik erzielt werden kann. Und gerade für derlei ständige Optimierungen bewährt sich eine zuverlässige automatische Speicherverwaltung häufig über Jahre, bevor man hier die Grenzen erreicht hat.

Nicht zuletzt können Programme auch in Hinblick auf die Ausführungsgeschwindigkeit in dem Zusammenspiel mit Garbage-Collection optimiert werden.

Bestimmte Arten von Programmen erzielen -- auch ohne Optimierung -- gerade mit Garbage-Collection um Faktoren höhere Geschwindigkeiten als etwa auf traditioneller C-Speicheranforderung basierende Pendants. == Klassenbibliothek ==

Die Framework Class Library (FCL) umfasst einige Tausend Klassen, die in so genannte Namensräume (Namespaces) unterteilt sind. Die Klassen erfüllen Aufgaben wie z.B. das Formatieren von Text, das Verschicken von E-Mails, aber auch das Generieren von Code. Die Unterteilung in Namensräume dient dazu, die große Menge an Informationen übersichtlicher zu gestalten. Beispielsweise befinden sich Klassen zu dem Generieren von Code im Namensraum System.Reflection.Emit.

Die Dokumentation der Klassen liefert der Hersteller in seinem Software Development Kit (SDK) mit (siehe unten).

Der Hersteller Microsoft bietet .NET in verschiedenen Formen an. Als reine Laufzeitumgebung samt benötigter Klassenbibliotheken (Framework), als kostenloses SDK für Entwickler, als kostenpflichtige integrierte Entwicklungsumgebung (IDE) in Form des "Microsoft Visual Studio .NET".

Seit "Windows Server 2003" bietet Microsoft darüber hinaus Server-Betriebssysteme an, die eine bereits integrierte .NET Laufzeitumgebung bereit stellen. Bei Vorversionen muss die Laufzeitumgebung manuell installiert werden, sofern sie zu einer unterstützten Windows-Variante gehört. Unter Windows 3.1 ist .NET nicht lauffähig, auf Windows 95/98/Me/NT jeweils ca. mit bestimmten Einschränkungen, die Programmierung von Webanwendungen (ASP.NET) etwa läuft ca. ab Windows 2000. Auf Nicht-Windows-Systemen wird .NET von Microsoft offiziell nicht unterstützt – ist also ca. in der Theorie plattformunabhängig. Allerdings existieren die bereits erwähnten Open-Source-Projekte, die .NET auch für andere Plattformen (z.B. Linux) eingeschränkt verfügbar machen.

Für Handhelds und Mobiltelefone, die unter Windows CE bzw. Windows Mobile 2003 laufen, existiert eine abgespeckte Version der .NET-Laufzeitumgebung in Form des Compact Frameworks . Es lässt sich aber ca. unter Verwendung des kostenpflichtigen Visual Studio .NET 2003 oder neuer für diese Plattform entwickeln. Mit Visual Studio 2005 sind für Privatanwender kostenlose Einfachversionen erhältlich (ab Juli 2004 in Vorabversion).

Dieser Artikel befindet sich derzeit in dem Reviewprozess. Hilf mit, ihn zu verbessern!

• Microsoft .NET Framework (http://msdn.microsoft.com/netframework)
• Microsoft .NET Framework (deutsche Info) (http://www.microsoft.com/germany/ms/entwicklerprodukte/visualnet03/framework11/produkt.htm)
• Mono-Projekt (http://www.mono-project.com/)
• Portable.NET-Projekt (http://www.dotgnu.org/)
• .NET UserGroup (http://www.netug.de/)
• Entwicklung einer Java-VM für .NET (http://www.ikvm.net/)